The present invention relates to object-oriented software systems and related methods for digital computers.
Using object-oriented software techniques, software applications for digital computers are created by combining software objects. To facilitate this process, object-oriented software systems typically provide an architecture specification, called the object model, which enables all objects developed to the specification to work together seamlessly in an application. Examples of object models would include the Object Management Group""s Common Object Request Broker Architecture (CORBA), and Microsoft""s Common Object Model (COM.) Such systems also typically provide software, called the object system, which implements the basic features provided for in the object model.
There are numerous object systems, some very general in nature such as Microsoft""s Object Linking and Embedding (OLE) (which follows the COM object model), or IBM""s Distributed System Object Model (DSOM), and Iona""s ORBIX, (which both follow the CORBA object model). See for example: the OLE 2 Programmers Reference, Volume 1 and 2, Microsoft Press, 1994; the IBM SOMobjects Developer Toolkit V2.0, Programmers Reference Manual, 1993; Iona ORBIX, Advanced Programmers Guide, 1994; and The Common Object Request Broker: Architecture and Specification Ch. 6., OMG, 1991; these references are hereby incorporated herein by reference.
Other object systems are designed to provide specific functionality, for example, in areas such as groupware or relational databasexe2x80x94e.g. Lotus Notes. Still other object systems are specific to particular to applicationsxe2x80x94e.g. Novell""s AppWare Bus, Hewlett Packard""s Broadcast Message Server, and Microsoft Visual Basic""s VBX object mechanism. See for example: the Lotus Notes Programmers Reference Manual, 1993; the Novell Visual AppBuilder Programmers Reference Manual, 1994; the Hewlett Packard Softbench BMS, Programmers Reference Manual, 1992; Microsoft Visual Basic 3.0 Professional Features Book 1, Control Development Guide, 1993; these references are also hereby incorporated herein by reference.
In creating a software application it is desirable to combine objects from various object systems, because different object systems are best suited to different tasks, and because the best solution is usually built from the best parts (i.e. objects.) However, objects from various object systems don""t naturally work together for a number of reasons.
Object systems are rendered incompatible due to differences in the means by which objects are created, methods are called and properties are set in each object system, including differences in the fundamental mechanisms used as well differences in low-level calling conventions such as the physical layout of types and classes. For example at the fundamental level, some object systems, such as COM, use direct C++ calling mechanisms. Others such as DSOM pre-process source code so that in place of a direct call, a function from the object system is called which, in turn, returns a pointer to the real method. This pointer is dereferenced to actually call the method. Still other object systems such as OLE Automation provide specialized functions developers must use to call methods (this is often referred to as a Dynamic Invocation Interface or DII). These functions take the method to be called as an argument, as well as the method""s arguments (usually packed into a particular format), and they call the method for the developer. There are numerous other broad differences and variants in fundamental calling mechanisms. Each of these fundamental mechanisms also differ in detail. For example, CORBA requires an environment pointer argument (and has an optional context argument), while other object systems do not.
In addition to the vast differences in fundamental calling mechanisms, there are many differences in low-level calling conventions, sometimes referred to as procedure calling conventions. For example, different object systems handle the return value from methods differently when the type of the return value is a float or a structure. In one case the value may be returned on the processor stack, while in another the value may be placed in a register. Thus, using the return value of a method from a different object system would result in an error. Other examples of differences in procedure calling conventions would include how structures are packed into memory, and how arguments are placed on the stack.
Various object systems also support various types which may not be compatible with other object systems. Simple examples of types include language types such as integers, floats, etc. More complex language types include arrays, strings, and objects. There are also semantic types such as xe2x80x9cvariable typesxe2x80x9d like the CORBA Any, and the COM VARIANT. Semantic types differ from language types in that they have a particular semantic meaning to the system. While certain semantic types may conceptually mean the same thing among various object systems, their corresponding language representation and implementation may be entirely different. A common example is strings. In COM, strings are represented using a xe2x80x9cBSTRxe2x80x9d (a non-NULL terminated string which contains length information), while in CORBA, strings are the traditional C language byte array (NULL terminated with no length information). As a result, a COM object couldn""t pass a BSTR to a CORBA object because any functions that operate on strings, such as copying and comparison, used in the CORBA object would fail. Likewise, while xe2x80x9cvariable typesxe2x80x9d such as the CORBA Any and the COM VARIANT xe2x80x9cmeanxe2x80x9d the same thing, they aren""t compatible.
In addition, object systems have various rules about lifecycle management which may be incompatible. The term lifecycle management refers to the process required when creating, storing, and deleting objects. For example, COM requires developers to perform reference counting so objects can be automatically deleted. Relational databases have much more sophisticated lifecycle management, while CORBA has only very simple lifecycle management with no reference counting.
The above issue of lifecycle management is challenging because often, objects are passed as arguments to methods. Consider the case where an object in one object system calls a method of an object in a foreign object system and passes an object (from its object system) in as an argument to the method. Since the foreign object system only understands its own objects, the object argument must be dynamically converted to a corresponding object in the foreign object system. In other words, a new object must be created in the foreign object system to match the original object passed in as an argument. All such dynamic lifecycle managementxe2x80x94object creation, with its corresponding object destructionxe2x80x94must be handled properly if object system interoperability is to work.
Another aspect of object system interoperability is differences in exception and error handling among object systems. Errors or exceptions encountered within the code for an object typically must also be dealt with in the object which called the code. If the two objects are from different object systems, and the error handling mechanisms are incompatible, software failure may result.
Various object systems provide different ways to dynamically query for information about objects. This functionality is required for object systems that provide a general macro script recording facility as well as for object systems that provide distributed computing capabilities. See for example Ch. 1-3 of Microsoft""s OLE 2 Programmers Reference Volume 2, Apple""s Inside Macintosh: Interapplication Communication Ch. 8 (hereby incorporated herein by reference), or the Object Management Group""s The Common Object Request Broker: Architecture and Specification Ch. 6. Thus, incompatibilities in the mechanisms to query for information about objects results in significant restrictions in the ways that objects may be used in other object systems.
As mentioned previously, object systems each have different design goals. As a result, each typically has functionality that isn""t available in other object systems. Two examples of this are: CORBA namespaces (which COM doesn""t have); and COM objects supporting multiple interfaces (which CORBA doesn""t have). Software errors can result if an object is asked to perform some action that is only available in another object system.
In summary then, a sought after goal has been to provide interoperability among various object systems. Different object systems place different requirements on objects, so specialized software systems are required to enable interoperability. The prior art includes approaches to providing interoperability between object systems. Three solutions are of interest: stub function wrappers; a common wire protocol; and dynamic converters.
With the stub function wrapper method, an automated tool is used to generate stub functions which xe2x80x9cwrapxe2x80x9d objects in code that follows the specification of another object model. That is, the tool creates an object class in the foreign object system that contains only the code necessary to forward requests to the native object. This xe2x80x9cstubxe2x80x9d code is then compiled and linked into an application. The stub function method is exemplified by the COM interoperability provided with IBM""s DSOM for Windows. Using it, developers who have DSOM objects and want to use them from within COM use an automatic tool to generate source code for corresponding COM objects. The source code for the COM objects is simply a set of stub functions which forward calls to DSOM. For example, when the COM application calls a method of the COM object, the method simply re-calls the DSOM version of the method.
One automated tool to create a set of stub function wrappers provides one-way interoperability between two object systems. To provide two-way interoperabilityxe2x80x94as is required for dynamic lifecycle management, a second tool has to be written. If an additional object system is to be supported, and full interoperability among all three systems is required, an additional four automated tools must be written. In fact, the number of such tools required for interoperability among N object systems is N2-N. In addition, for each object class, N2-N versions of stub wrapper functions must be generated, managed and supported. Given that any particular application will have hundreds of classes, this is a significant disadvantage. Furthermore, this method provides no support for the remainder of interoperability issues such as dealing with type conversions, low level calling convention differences, lifecycle management differences, differences in error and exception handling, querying, or functionality differences. As a result, users of the object must code such conversions into their software manually, making it apparent that the object is from another object system (i.e. the object is clearly not indistinguishable from native object.) Finally, support for new object systems is not dynamic, so code must be recompiled and relinked.
Dynamic converters are designed to provide interoperability between two object systems that both support a dynamic invocation interface (DII). A DII xe2x80x9cdynamically invokesxe2x80x9d methods. That is, a DII is a set of functions that will call an object""s methods for the developer dynamically, and pass arguments to the methods using a pre-defined convention, rather than requiring that the call be compiled into the application. A dynamic converter is a hard-coded map between two DIIs. When a method is called, the converter code packages the information into a format suitable for the DII of the second object system, then calls the method.
As with the stub wrapper mechanism, this approach requires N2-N converters in order to support N object systems. Furthermore, dynamic converters only work with object systems that support a DII. Moreover because they use a DII their performance suffers. And, as with the stub wrapper method, this method provides no general support for the remainder of interoperability issues such as dealing with type conversions, differences in error and exception handling, querying, or functionality differencesxe2x80x94thereby being unable to provide foreign objects which are indistinguishable from native objects.
The common wire protocol method is designed to work with distributed object systems, that is, object systems whose objects may be located on different computers having different machine architectures. With the common wire protocol method, object systems which share a common underlying distributed computing system (DCS)xe2x80x94the xe2x80x9ccommon wirexe2x80x9dxe2x80x94can interoperate. The common distributed computing system enables object systems to transfer language data types, because a non N2-N language data type transfer mechanism is provided by the DCS.
This approach addresses the issue of low level calling conventions and provides mapping of low level data types. The complexity of supporting N object systems depends directly upon whether the object systems share the same object model. If so, there is no need to provide interoperability between fundamental calling convention differences, semantic type differences, lifecycle management differences, differences in error and exception handling, or functionality differences, and each object system requires only to support the DCS. This case would be exemplified by interoperability among various CORBA object systems such as IBM""s DSOM, Iona""s Orbix, Hewlett Packard""s DOMF, etc. which can each use the Open Software Foundation""s Distributed Computing Environment (DCE).
If interoperability is among object systems that don""t share a common object model, the approach requires N2-N converters to deal with the remaining issues. Furthermore, this method doesn""t work at all if the object systems which must interoperate are not built on top of a shared distributed computing system. And the approach is very resource intensive due to the reliance on a DCS. While it handles transfer of simple data types, it provides no general mechanism to handle more complex type conversions, lifecycle management differences, differences in error and exception handling, querying, or functionality differencesxe2x80x94resulting in similar deficiencies to other prior art.
Along with the above prior art directly addressing the issue of object system interoperability, there is other prior art addressing various elements of the problem, each in a different context.
There have been a number of systems that have dealt with the issue of mapping between different low-level calling conventions. In U.S. Pat. No. 4,736,321, a method was described wherein an interactive language workspace, APL, was able to call external language procedures. In it, FORTRAN functions were declared to the APL environment, and the APL environment mapped the APL calls and arguments into FORTRAN calling conventions. The method in this patent is specific to the interactive APL language environment and provides unidirectional access from APL to multiple languages (FORTRAN and Assembler). The method doesn""t support bi-directional access among any number of languages, and doesn""t work among compiled language code systems.
A similar mechanism was described for Prolog in U.S. Pat. No. 5,274,821 wherein a Prolog language procedure could call external language functions and vice versa. In this patent, the mapping was accomplished using a table driven approach. That is, mapping of Prolog to multiple languages, and mapping multiple languages to Prolog was accomplished by describing the low level calling convention to the system in a table. This information was used at execution time to dynamically perform the mapping. As with the method in U.S. Pat. No. 4,736,321, this method is specific to an interactive language environment, in this case, Prolog. It provides bi-directional mapping from Prolog to N languages, but not among N languages. The method doesn""t work among compiled language code systems, and in any case would require N2-N conversion tables.
A mechanism was described in U.S. Pat. No. 5,210,876 wherein an interpreter is able to call a compiled procedure, which in turn, calls an interpreted procedure. The means was to generate a new intermediate compiled procedure which is called by the original compiled procedure. The new compiled procedure was then dynamically linked with the original compiled procedure. The new generated procedure converted arguments to the format required by the interpreter, then called the interpreted procedure. Finally, the results were converted back to those required by the compiled language. As with other prior art, this patent facilitates an interpreted environment calling compiled language code. And as with other prior art, N2-N code generators would be required to support procedure calling convention conversion among N systems.
U.S. Pat. No. 5,097,533 describes a method for interfacing various pre-determined computer languages to a single software system. In it, code is written for each language to map from the API in the language to a single API for the underlying software system. This patent maps procedure calling conventions from N languages to one by writing code to perform the mapping for each. The method does not work for conversion among N language conventions, and in any case would require N2-N code blocks to be written.
In U.S. Pat. No. 5,146,593, a method is described wherein a single software interface is used to call a plurality of procedures. In fact, this is but one example of a DIIxe2x80x94a DII designed for mapping to different programming languages. In it, the method uses tables to describe the low level calling conventions of the particular language. The user (i.e. the software developer wishing to make the calls) links the DII interface with their application and uses it to make all their calls by passing it a procedure identifier, and data structures in a predefined format. The method doesn""t support interoperability among N language calling conventions, and would also require N2-N tables should the approach attempt to be extended for that purpose.
The above patents share the fact that they are designed to provide a mechanism to deal with the differences between low-level calling conventions of various languages. With the exception of U.S. Pat. No. 5,210,876 they each provide a means of converting various language types as well. However, they don""t address the issue of differences between high level calling conventions. In fact, they each a provide a different high level calling convention, so they have no need to. Nor do they provide any support for mapping between semantic types.
Other patents, for example U.S. Pat. No. 5,187,787 have dealt with the issue of mapping between semantic types. In this patent, mapping between semantic types was but one element of a larger system used to provide a communications interface which decoupled two software applications. In it, the semantic types used in the communication were designed by to be self-describing. The patent teaches that the semantic description must be separated from the data representation for interoperability. Further, developers use a system API to access data, which may be located elsewhere, and in another semantic form. Thus, the mechanism requires explicit knowledge on the part of the developer to use the decoupled data, and is analogous to a single DII, with the same consequent limitations.
In U.S. Pat. No. 5,278,978, a method was described to transfer information between two databases. As a part of the system, a mechanism was described to map between both language types and semantic types. Each language type was tagged with a canonical identifier called a marker descriptor. Likewise, separately, each semantic type was tagged with a canonical identifier called a type definition. When data was received from another database, the descriptions were used to perform a conversion. Each database was required to have predefined descriptions of all other machine environments and semantic types, i.e. N2-N conversion descriptions, because conversion was performed at the receiving database.
This invention provides in some embodiments a single system in a digital computer enabling software objects from multiple heterogeneous object systems to interoperate bi-directionally and to be combined in the creation of a larger software system. Objects from a foreign object system are unmodified, yet appear to be native to the object system in which they are used or accessed. Support for additional object systems may be added dynamically while the system is executing, thereby adding bi-directional interoperability with all other supported object systems. A mechanism is also provided whereby features in one object system may be supported in other object systems without the necessity of modifying objects.
For a foreign object to be used in another object system, the system of these embodiments constructs a native proxy object (indistinguishable from other native objects) for the real foreign object. The proxy object contains an identifier to the real object, as well as a pointer to a software description of how to access and manipulate the objectxe2x80x94e.g. how to call its methods, set its properties, and handle exceptions. When the proxy object is manipulated, it follows the instructions in the software description which, in turn, results in the corresponding manipulation of the foreign object.
The system of these embodiments provides a number of object-oriented frameworks with default implementations. There are frameworks to: dynamically locate objects in an object system-specific or uniform namespace; describe the characteristics of an object class or instance; describe both semantic and language types; xe2x80x9cexecutexe2x80x9d the software descriptions to forward manipulations of the proxy object to the real foreign object; handle errors and exceptions; create, copy, destroy, and manage the lifecycle of objects; and a framework to xe2x80x9cexportxe2x80x9d object definitionsxe2x80x94i.e. to make objects in one object system appear as object classes indistinguishable from native object classes temporarily or permanently in other object systems.
In addition, there is a framework to add extra information to the description of any object class. Such added information is called a xe2x80x9cmixinxe2x80x9d. When an object is manipulated in a way it doesn""t support, for example if it is asked to return the middle element of a collection but it doesn""t support such a method, the system asks the mixins associated with the object if they can support the request. If so, they take over and perform the request. In this way, a general mechanism is provided to extend the capabilities of objects in an object system with features of other object systems that they wouldn""t naturally support.
Extensions to the default implementations of each of the above frameworks are grouped by object system, and packaged into libraries called Object System Adapters (OSAs). OSAs can be dynamically loaded into the OSA Registry framework of the system, thus adding everything necessary to dynamically support new object systems and provide full interoperability with other object systems.
It will be obvious to those skilled in the art that the system may be used stand-alone, or embedded as an element of a larger software system.
Further embodiments of the invention are also provided:
(A) a system and method to enable the creation of a xe2x80x9cuniversal objectxe2x80x9d, i.e. a single object which appears to be implemented in a plurality of object systems simultaneously, and which can dynamically change which object systems it supports. Said system also enables the creation of objects in individual, application, and server configurations. Further, such objects may be based upon interpreted or compiled language technology;
(B) a system and methodxe2x80x94either library-based or interactivexe2x80x94to enable the construction of object classes including the aforementioned xe2x80x9cuniversal objectxe2x80x9d, where such system in the creation of said object classes, may constitute a subclass of, incorporate, or embed instances of, objects from a plurality of object systems;
(C) a system and method to enable object classes and objects to be relocated among applications and servers in one or more object systems while the applications and servers are executing, and without disruption of software utilizing said object classes and objects, even if it too is executing.